home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1989 / Jun 89 / V0069-Re Docs and Obj pas-Jun89 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.5 KB  |  86 lines  |  [TEXT/GEOL]
  1. Item    4659915                         22-June-89        11:52
  2.  
  3. From:   CREMER.M                        Cremer, Mike
  4.  
  5. To:     D2086                           Efficient Field Svc, C Faith, PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    Re: Docs and Obj pascal
  10.  
  11. Curtis,
  12.  
  13. If I understand the problem correctly, you have a situation where you want a
  14. "background" document to be in the command chanin so it can determine if it
  15. needs to do something when an unhandled command comes along.
  16.  
  17. My difficulty with this line of thinking is the Mac user interface hinges on
  18. the concept of user-initiated actions affecting a user-known target.  How is
  19. the user to know that the menu command or keystroke is going to hit the third
  20. document back?  That makes the application look more like a huge filter, with
  21. each document straining out only the commands it can handle.  How would you
  22. handle Undo?  Would it Undo the last command that was processed, irrespective
  23. of whose it was?  Or would Undo reflect only the changes made to the "current"
  24. (i.e. frontmost) document?
  25.  
  26. > Say I have one list open [and] I want to get another up.  I close the list
  27. > window.  Now since there was a letter open already that letter document
  28. > gains control.  I cannot open the new list.
  29.  
  30. I'm not clear on whether the user or the application initiated this sequence.
  31. Did your app decide it needed a new list window?  Or did the user perform some
  32. action to indicate she wanted a new list window?  And if the latter, why do it
  33. while she was working on a letter?  This would fit your argument if the user
  34. performed some action on the letter, and as a side-effect, it disposed of an
  35. old list and created a new one (in a different document).  In this case, it
  36. seems more logical for the letter to have some knowledge of the list, and
  37. effect the changes itself, instead of passing the command that initiated the
  38. change along to anyone who wanted it.
  39.  
  40. > I don't think any user interface standards would be violated by having
  41. > the menus enabled when the letter document is at front.
  42.  
  43. This way madness lies.  What happens to commands that several documents could
  44. handle?  How does the user distinguish who the action is targeted for?  (see
  45. above).  What if I choose "Revert…", which gets handled by the frontmost
  46. document, but I really intended the Revert for a background document?  And now
  47. I can't Undo the Revert, and all my changes to the frontmost document have been
  48. blown away... :-(  The problem here is that some commands affect the front
  49. document, and some the background, but the sets are not mutually exclusive.
  50. The user may not know beforehand which document will handle the command,
  51. especially if there happens to be an open windowless document lurking behind
  52. the screen, waiting to eat unsuspecting commands and giving no indication that
  53. it did so.  This is not good.
  54.  
  55. > Having to click on a window of the TDatabase object to gain access to
  56. > those commands is entirely too modal and messy.
  57.  
  58. I like to think of an application that can handle multiple document _types_ as
  59. being several applications.  Running MacWrite, MacPaint, and MacDraw under
  60. MultiFinder and running MySuperDuperWritePaintDraw would be equivalent from a
  61. user persepctive.  The Write, Paint, and Draw elememts are distinct; no user
  62. would have trouble making the distinction.  Perhaps in a database application
  63. the distinction between functions and documents is blurred.  I like Larry's
  64. idea of a the database being controlled by the TApplication, and TDocuments
  65. representing forms or slices of database information.  In fact, the first
  66. MacApp application I wrote did exactly this.  It works rather well, too.
  67.  
  68. re: Documents handling commands even when no window is open, I agree with Larry
  69. that anything the user can change should have a visible component so the user
  70. can monitor the effect she is having (see above).
  71.  
  72. I do not want to be a NO-NO-NO-NEVER-NEVER-NEVER screamer.  The concept of all
  73. documents being in the command chain is not evil per se.  In your application,
  74. you can do whatever you like, and the acceptance it receives from users will be
  75. its ultimate measure.  However, document command chains should be an option
  76. taken only by those who really understand what they are doing (can you imagine
  77. debugging such a creature?).   Since the onus of responsibility for ensuring
  78. correct behavior rests on the programmer, those who program "normal"
  79. applications should not have to exert any extra effort to work around the
  80. document "feature."
  81.  
  82. Food for thought, anyway.
  83.  
  84. $mike cremer
  85.  
  86.